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Comput r-lmplemented Method of, and System for, 
Messaging in a Computer N twork 

FIELD OF THE INVENTION 

5 

The present invention generally relates to methods of, and systems for, 
messaging in a computer network. More particularly, the invention relates to 
methods and systems where user modifications of one or more data objects 
maintained by a first participant system of the computer network are 
10 communicated to at least one other participant system of the computer network 
according to certain criteria. 

BACKGROUND OF THE INVENTION 

15 In distributed computer networks, communication between the various 

distributed participant systems of the network is often through asynchronous 
exchange of messages. In asynchronous messaging, software program 
applications send and consume messages. The message exchange is 
asynchronous in that an application sending a message does not need to wait 

20 for a remote application to receive that message. Thus, there is no need for all 
elements of the infrastructure linking the computers on which the applications 
are run to be available at all times. 

Generally, communication between participant systems of a distributed 
25 computer network can be according to a pessimistic communication protocol or 
an optimistic communication protocol. As an example, a computer system of a 
purchaser of goods may run a software program application that allows the 
purchaser to electronically place a purchase order. The purchase order 
application generates and stores locally a first data object representing the 
30 order, and effects sending of a message containing the data object, i.e., the 
order, via the computer network to an order processing software program 
application run on another computer system at the site of a supplier of the 
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requested goods. The order processing application handles and processes 
incoming orders. Once the order processing application receives a new 
purchase order, it creates and stores locally a second data object that 
corresponds to the first data object. 

5 

In practice it frequently happens that a purchaser, after having successfully 
placed an order with a supplier, wishes to change (modify) his order, for 
example, because the quantity or size of the required goods has changed. 
Thereafter, the purchaser may wish to modify his order a second time, and 
10 perhaps yet even more times. 

If a pessimistic communication protocol is used for communication between the 
purchaser and supplier systems, a modification of the order by the purchaser is 
allowed only until after a confirmation message sent from the supplier system 

15 has been received by the purchaser system in response to an earlier 

modification. In other words, the purchaser, who has just entered a modification 
into his system, has to wait until a message (answer) confirming receipt of the 
modification is received from the supplier system, before he is allowed to enter 
another modification. The supplier's confirmation can be positive (he accepts 

20 the modification) or negative (he rebuffs the modification). On the other hand, if 
an optimistic communication protocol is used, the purchaser can enter a 
modification of his order even before having received a confirmation of an 
earlier modification from the supplier system. 

25 Pessimistic communication protocols are usually employed where conflicts 

between the participant systems may easily occur, e.g., where a supplier is not 
sufficiently flexible to respond to late modifications of an order short before start 
of a production run or to handle plural modifications within a short period of 
time. For example, if an order is sent from a purchaser to an outside supplier, 

30 modifications of the order are likely to be acceptable for the supplier only well 
before execution of the order. This is particularly true if the purchaser and 
supplier resort to software products from different providers for handling their 
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electronic business matters. A standard pessimistic communication protocol 
often used in today's world of electronic commerce is, e.g., RosettaNet. 

An optimistic communication protocol is convenient in a situation where the 
5 supplier is highly flexible and able to react on modifications of an order even 
short before commencing execution of the order. This is often true where 
purchaser and supplier, or more generally collaborating business partners, rely 
on software products from the same software provider using similar or the same 
standards, procedures, interfaces, data structures, instruction sets, etc. It is also 
10 determinative for the choice of the type of communication protocol used 

whether or not the systems are able to store and visualize process conflicts as 
part of their data design and business process. 

When designing and programming a scheme for the communication between 
15 participant systems of an asynchronous messaging computer network, a 
software developer, or a team of developers, hitherto face a dilemma of 
choosing whether to implement an optimistic protocol or a pessimistic protocol. 
Voting for an optimistic communication protocol implies forgoing the openness 
of a pessimistic communication environment, i.e., the possibility of having most 
20 diverse software systems of different manufacturers collaborate through a 
computer network. Electing a pessimistic communication protocol means 
waiving flexibility and ease of use of an optimistic communication environment. 
Thus, it is highly desirable to have a communication protocol that preserves 
both openness of a pessimistic system and customer friendliness of an 
25 optimistic system. 

SUMMARY OF THE INVENTION 

The present invention provides in one aspect a computer-implemented method 
30 of messaging in a computer network, the computer network comprising a 
plurality of at least two computer-based participant systems communicating 
through asynchronous exchange of messages, a first one of the participant 
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systems maintaining one or more data objects, the first participant system 
arranged to send messages to at least one other participant system to notify 
said other participant system of modifications of said one or more data object 
entered through the first participant system, the method comprising the steps of: 
5 providing a status object in relation to each data object, the status object 

comprising one or more status fields for storing information representative of at 
least one of a delta value applied to the respective data object as a result of one 
or more modifications and a total value of that data object after application of 
the one or more modifications; providing a modification status flag in relation to 

10 each data object; providing a communication status flag in relation to each data 
object; each time a modification of a respective data object is entered, updating 
the respective status object so as to reflect the modification, and checking the 
respective modification status flag; if it is determined that the modification status 
flag indicates a first modification status, setting the modification status flag to a 

15 second modification status; in response to setting the modification status flag to 
the second modification status, checking the respective communication status 
flag; if it is determined that the communication status flag indicates a first 
communication status, retrieving the respective status object and sending a 
notification message containing the retrieved status object from the first 

20 participant system to the other participant system; upon sending of the 

notification message, setting the respective communication status flag to a 
second communication status and resetting the respective modification status 
flag to the first modification status; and upon receipt of a confirmation message 
from the other participant system by the first participant system, resetting the 

25 respective communication status flag to the first communication status, the 
confirmation message confirming receipt of the notification message by the 
other participant system. 

In another aspect, the present invention provides a computer-implemented 
30 system for messaging in a computer network, the system comprising a first 
computer adapted to run one or more software program applications in 
accordance with inputs, the first computer provided with a computer program 
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product providing computer-executable program code that, when loaded into 
the computer, causes the first computer to: provide a status object in relation to 
each of one or more data objects maintained by said one or more software 
program applications, the status object comprising one or more status fields for 
5 storing information representative of at least one of a delta value applied to the 
respective data object as a result of one or more modifications entered by said 
user and a total value of that data object after application of the one or more 
modifications; provide a modification status flag in relation to each data object; 
provide a communication status flag in relation to each data object; each time a 

10 modification of a respective data object is entered, update the respective status 
object so as to reflect the modification, and check the respective modification 
status flag; if it is determined that the modification status flag indicates a first 
modification status, set the modification status flag to a second modification 
status; in response to setting the modification status flag to the second 

15 modification status, check the respective communication status flag; if it is 

determined that the communication status flag indicates a first communication 
status, retrieve the respective status object and send a notification message 
containing the retrieved status object to at least one second computer; upon 
sending of the notification message, set the respective communication status 

20 flag to a second communication status and reset the respective modification 
status flag to the first modification status; and upon receipt of a confirmation 
message from the second computer, reset the respective communication status 
flag to the first communication status, the confirmation message confirming 
receipt of the notification message by the second computer. 

25 

The present invention is based on a pessimistic global approach in that it 
requires, after sending of a notification message by the first participant system, 
receipt of a confirmation message from the other participant system before 
allowing the first participant system to send a next notification message. At the 
30 same time, the invention supports an optimistic local (internal) approach in that 
it allows a user to enter modifications at a time of his choosing, without requiring 
the user to wait for earlier modifications to be confirmed. In this way, 
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advantages such as tolerance and flexibility of optimistic communication 
protocols and advantages such as openness of pessimistic communication 
protocols can be combined. 

5 The status object is updated each time a modification is entered regardless of 
whether or not the pessimistic protocol used for communication between the 
participant systems allows sending of a notification message. Thus, in a case 
where a user makes multiple changes to a data object, the information 
contained in the status object reflect these multiple changes. Once the 
10 pessimistic protocol allows sending of a notification message (as indicated by 
the communication status flag being set to the first communication status), the 
current object status is read, which may be comprised of plural modifications. In 
this way, multiple modifications can automatically aggregate to one notification 
message. 

15 

The modification status flag indicates whether or not the respective data object 
is in a modified state that is yet to be communicated to the other participant 
system. Specifically, the first modification status indicates that the data object is 
either in its initial state or that any modifications of the data object have already 
20 been communicated to the other participant system. On the other hand, the 

second modification status indicates that the data object has been changed but 
no notification message has yet been sent that includes the respective change.. 

Checking a respective communication status flag preferably includes repeating 
25 checking that communication status flag if it is determined that the 

communication status flag indicates the second communication status, until it is 
determined that the communication status flag indicates the first communication 
status. 

30 In a preferred embodiment, a first display item is presented on a display of a 
graphical output device in relation to every data object of which the modification 
status flag indicates the second modification status. Also, a respective second 
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display item can be presented on the display in relation to at least one first 
display item, the second display item indicating part or all of the information 
contained in the status object of the corresponding data object. In this way, a 
graphical user interface can be generated that allows the user to keep himself 
5 informed of which modified data object(s) have still to be communicated to the 
other participant system. 

In yet another aspect, the present invention provides a computer program 
product providing computer-executable instructions that, when executed by a 

10 computer, cause the computer to: provide a status object in relation to each of 
one or more data objects maintained by one or more software program 
applications running on the computer, the status object comprising one or more 
status fields for storing information representative of at least one of a delta 
value applied to the respective data object as a result of one or more 

15 modifications entered by a user of the computer and a total value of that data 
object after application of the one or more modifications; provide a modification 
status flag in relation to each data object; provide a communication status flag 
in relation to each data object; each time a modification of a respective data 
object is entered, update the respective status object so as to reflect the 

20 modification, and check the respective modification status flag; if it is 

determined that the modification status flag indicates a first modification status, 
set the modification status flag to a second modification status; 
- in response to setting the modification status flag to the second modification 
status, check the respective communication status flag; if it is determined that 

25 the communication status flag indicates a first communication status, retrieve 
the respective status object and send a notification message containing the 
retrieved status object to at least one other computer; upon sending of the 
notification message, set the respective communication status flag to a second 
communication status and reset the respective modification status flag to the 

30 first modification status; and upon receipt of a confirmation message from the 
other computer, reset the respective communication status flag to the first 
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communication status, the confirmation message confirming receipt of the 
notification message by the other computer. 

BRIEF DESCRIPTION OF THE DRAWINGS 

5 

Further objects, features, and advantages of the present invention will become 
apparent from the following description taken in conjunction with the 
accompanying drawings in which: 

10 Fig. 1 is a schematic diagram illustrating an asynchronous messaging computer 
system according to one embodiment of the present invention; 

Fig. 2 is a flowchart diagram illustrating a messaging methodology according to 
one embodiment of the present invention; and 

15 

Fig. 3 is a schematic diagram illustrating a graphical user interface as it may be 
presented to a user of a computer station employed in the computer system of 
Fig. 1. 

20 DETAILED DESCRIPTION OF THE DRAWINGS 

Fig. 1 illustrates a simplified block diagram of a distributed computer system 
100 that comprises a plurality of at least two loosely coupled computer stations 
1 10, 1 1 1 , 1 12 ... linked to each other via a network 120. Computer stations 110, 

25 111,112... communicate over network 120 through asynchronous exchange of 
messages. Computer station 110 comprises a processor 130, a memory 140, a 
bus 150, and one or more input devices 160 and output devices 170 acting as 
user interface. The components of computer station 110 interoperate in a 
manner conventionally known in the art. Typically, computer stations 111,112 

30 ... will have similar components as computer station 110. Hence, components 
130 - 170 of computer station 110 may collectively illustrate corresponding 
components in other computer stations connected to network 120. Computer 
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stations 1 10, 1 1 1 , 1 12 ... are also referred to as remote computers. They can, 
e.g., be servers, routers, peer devices, or other common network nodes. 

Computer station 110 can, e.g., be a desktop personal computer, a laptop or 
5 notebook computer, a workstation, a minicomputer, a multiprocessor computer, 
a mainframe computer, a mobile computing device, a programmable personal 
digital assistant, or the like. Processor 130 can, for example, be a central pro- 
cessing unit (CPU), a digital signal processor (DSP), a micro-controller, or the 
like. 

10 

Memory 140 symbolizes components that allow to store data and/or instructions 
permanently or temporarily. Although memory 140 is illustrated in Fig. 1 as a 
distinct component part of computer station 110, it can be implemented by 
suitable storage resources within processor 130 itself (register, cache, etc.), in 
15 nodes of network 120, in other computer stations, or elsewhere. Specifically, 
memory 140 can include a read only memory (ROM) portion, e.g., for perma- 
nently storing program files, and/or a random access memory (RAM) portion for 
storing data such as variables and operation parameters. It can be physically 
implemented by any type of volatile and non-volatile, programmable and non- 
20 programmable, magnetic, optical, semiconductor and other information storage 
means conventionally known in the art, for example, hard disk, floppy disk, CD- 
ROM, DVD, DRAM, SRAM, EPROM, EEPROM, memory stick, etc. 

Memory 140 can store software program support modules such as, for exam- 
25 pie, a basic input/output system (BIOS), an operating system, a program library, 
a compiler, an interpreter, communication programs, driver, protocol converters, 
and application software programs (e.g., text processor, browser, database 
applications, etc.). 

30 The present invention is embodied in a computer program product (CPP) stored 
in memory 140 and/or in a storage location outside computer workstation 110, 
e.g., on a separate program carrier 180 that can be inserted in, and read by, 
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input device 160. The CPP generates program signals collectively called a 
"program". 

The CPP provides in a computer readable manner, program code executable 
5 by processor 130. The program code is comprised of instructions and, 
optionally, data and variables. When loaded, the program code causes 
processor 130 to carry out steps forming one embodiment of a method 
according to the present invention. A detailed description of the method steps 
will be given further below. The CPP controls operation of computer station 110 
10 and, if necessary, its interaction with other components of computer system 

100. It may be provided as source code in any suitable programming language, 
e.g., C++, or as object code in a compiled presentation. 

Although Fig. 1 illustrates the CPP as stored in memory 140, it may as well be 
15 located on program carrier 180 outside computer workstation 110. If the CPP is 
stored on program carrier 180, input device 160 will be adapted to allow inser- 
tion of program carrier 180 into input device 160 to retrieve the CPP. Program 
carrier 180 can be any computer-readable information carrier medium such as, 
for instance, a magnetic or optical disk. Instead of storing the program code in 
20 memory 140 or on program carrier 180, the CPP can also be provided to proce- 
ssor 130 in the form of program signals delivered through network 120 from a 
remote computer. The steps embodied by the program code of the CPP can be 
carried out solely within computer station 1 10 or in a distributed manner using 
additional components of computer system 100. 

25 

Input device 160 serves to input data and/or instructions for being processed by 
computer station 110. The term input device encompasses, for example, a 
keyboard, a pointing device (mouse, trackball, cursor direction keys), a reading 
device for reading information stored on a separate information carrier (e.g., a 
30 drive for reading information from a disk, or a card reader for retrieving data 

from a memory card), a receiver for receiving information transmitted to compu- 
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ter station 110 from other components of computer system 100 through a wired 
or wireless link, a scanner, etc. 

Output device 170 serves to present in a graphical manner, information resul- 
5 ting from processing activities within computer station 110. Output device 170 
can, e.g., include a monitor or display, a plotter, a printer, or the like. Similarly to 
input device 160, output device 170, while mainly communicating with a user 
through visual presentation of processing results, may also communicate with 
other components of computer system 100. Thus, output device 170 may 
10 communicate a processing result through a wired or wireless link to a remote 
recipient. 

Input device 160 and output device 170 can be combined in a single device. 

15 Bus 150 and network 120 provide logical and physical connections by 

conveying instruction and data signals. While connections and communications 
within computer workstation 110 are handled by bus 150, connections and 
communications between different computers stations of computer system 100 
and handled by network 120. Network 120 may comprise gateway and router 

20 computers dedicatedly programmed to effect data transmission and protocol 
conversion. 

Input and output devices 160, 170 are coupled to computer workstation 110 
through bus 150 (as illustrated in Fig. 4) or through network 120 (optionally). 
25 While signals inside computer workstation 110 will mostly be electrical signals, 
signals occurring across network 120 can be any signal type, e.g., electrical, op- 
tical, or radio. 

Network 120 can be any form of dedicated or public communications network 
30 providing wired and/or wireless access and wired and/or wireless signal trans- 
mission across network 120. It can, e.g., include the Internet, an intranet (a net- 
work linking some or all of the members of a specific group, such as within a 
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company), a LAN, a WAN, a wireless LAN, a public switched telephone network 
(PSTN), an integrated services digital network (ISDN), or a mobile communica- 
tions network such as a UMTS (Universal Mobile Telecommunications System), 
GSM (Global System for Mobile Communication), or CDMA (Code Division Mul- 
5 tiple Access) network. 

Communication between computers of computer system 100 can be effected 
using any suitable transmission protocols, mechanisms and data formats. A few 
examples include Transmission Control Protocol/Internet Protocol (TCP/IP), 

10 Hyper Text Transfer Protocol (HTTP), secure HTTP, Wireless Application Proto- 
col (WAP), Unique Resource Locator (URL), Unique Resource Identifier (URI), 
Hyper Text Markup Language (HTML), Extensible Markup Language (XML), 
Extensible Hyper Text Markup Language (XHTML), Wireless Application 
Markup Language (WML), Electronic Data Interchange (EDI), which governs 

15 the electronic exchange of business information between or within organizations 
and their IT (Information Technology) infrastructure in a structured format, an 
application programming interface (API), etc. 

Computer stations 110, 111,112... are equipped with software systems that 
20 include one or more software program applications. Typically, each computer 
station's software system will be adapted to generate and maintain one or more 
databases for storing data and variables related to a particular application run 
by the respective computer station. Each computer station 110, 111, 112 ... 
equipped with its associated software system can be referred to as a participant 
25 system, or simply participant. 

In a typical scenario, participant systems 110,111,112 run suitable business 
program applications that collaborate through exchange of messages to exe- 
cute a business activity electronically. Network 120 ensures transport and de- 
30 livery of such messages in an asynchronous fashion. The messages are produ- 
ced and consumed by the participants' software applications. The number of 
participants involved in a collaborative business activity will be at least two but 
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can be any number greater than that. Messages sent from one participant can 
be directed to only one other participant. Alternately, a message can be addres- 
sed to more than one other participant, e.g., to all other participants or a selec- 
ted group of participants, as the particular business activity may require. 

5 

A software program application is resident on computer station 110 that 
includes a program code portion for generating and maintaining one or more 
data objects DOI, 0O2, D03 ... Data objects DOI, D02, D03 ... represent 
business-related information objects such as, e.g., a customer order, a set of 

10 financial, budgeting, or accounting figures, a number of items on stock, etc. A 
modification applied to a respective one of data objects DOI, D02, D03 ... can, 
e.g., correspond to a change in an order position in a customer order (different 
quantity, size, color or the like of goods ordered), an update of financial, 
budgeting, or accounting figures, an updated in the number of items on stock 

15 after execution of one or more customer orders, etc. The data of data objects 
D01, D02, D03 ... can be any data type and format including scalar data, 
structured data, or character/string data. 

The software program application resident on computer station 110 includes 
20 another program code portion for enabling a user to enter a modification of any 
of data objects DOI , D02, D03 ... For example, this program code portion can 
be arranged to cause generation of a graphical user interface in which a 
document is opened that displays the data of a particular one of data objects 
DOI, D02, D03 ... as presently stored. Entry of a modification can, e.g., be by 
25 means of a mouse device and a keyboard of computer station 1 1 0. The 

program may provide for an authorization check to determine whether or not the 
user is authorized to apply modifications to the particular data object. Of course, 
many other procedures and formats of entering modifications of data objects 
DOI, D02, D03 ... are conceivable and available to those skilled in the art, and 
30 the invention is not intended to be limited to a particular procedure and format. 
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Yet another program code portion of the software program application resident 
on computer station 110 serves for generating and maintaining a status object 

501, S02, S03 ... in relation to each data object DOI, D02, D03 ... Each 
status object SOI , S02, S03 . . . provides a current view of the corresponding 

5 data object DOI, D02, D03 wherein the current view reflects any 

modifications applied to the corresponding data object DOI , D02, D03 ... To 
this end, each status object SOI , S02, S03 ... may comprise one or more 
status fields as can be seen from the enlarged view of status object SOI in Fig. 
1 . There may be a first status field SF1 in each status object SOI , S02, S03 ... 

10 for storing information on a delta value applied to the corresponding data object 
as a result of one or more modifications. The delta value represents an accrued 
delta indicating the accumulated change of the respective data object as a 
result of the one or more modifications. Initially, i.e., upon establishment of the 
corresponding data object but before a first modification thereof, the delta value 

15 is set to zero. Alternatively or additionally, there may be second status field SF2 
for storing information on a total value of that data object after application of the 
one or more modifications. The total value represents an overall metric of the 
corresponding data object and is initially set to the data object's initial total 
value. 

20 

Optionally, there may be another status field SF3 for storing information on a 
modification history of the data object associated with the particular status 
object. The modification history may include a counter indicating the number of 
modifications entered and/or include a time stamp in relation to every modifi- 
25 cation indicating the time of entry of the respective modification. 

The data objects DOI, D02, D03 ... and the associated status objects SOI, 

502, S03 ...are conveniently stored in memory 140 but can be deposited in 
any other persistent storage location outside computer station 110. 

30 

Each time a user of computer station 110 enters a modification of one or more 
of data objects DOI, D02, D03 ... the program code portion maintaining the 



15609-018001 / 2003P00433 US 



- 15- 

status objects SOI, S02, S03 ... effects an update of the corresponding status 
object(s). Updating involves at least one, and preferably both, of updating the 
accrued modification delta value stored in status field SF1 and updating the 
total value stored in status field SF2. Optionally, it may also include updating the 
5 modification history stored in status field SF3. 

As an example, it is assumed that data object DOI stores the number of items 
available on stock with regard to a specific product. Initially, there may be 20 
items on stock. Thus, the corresponding status object SOI will initially be set to 

10 (0; 20; ...) where "0" indicates the delta value, "20" indicates the total value, and 
the ellipses stand for any further status elements that may be present in status 
object SOI such as the modification history. In case a user operating on data 
object DOI from computer station 110 removes five items from the stock, he 
enters the corresponding modification of data object DOI , causing status object 

15 SOI to be updated to (5; 15; ...). Thereafter, two items may be added by the 
user to the stock, resulting in an update of status object SOI to (3; 17; ...). 

Computer system 100 is configured as a distributed system where the same 
data can be worked on from different computers. To this effect, computer 

20 stations 111,112... store "copies" of one or more of data objects DOI , D02, 
D03 ... stored on computer station 110 with these copies representing the 
same data as data objects DOI, D02, D03 ... For example, and as illustrated 
in Fig. 1 , computer station 1 1 1 may store a data object DOI' that represents the 
same data as data object DOI , and computer station 112 may store a data 

25 object D02" representing the same data as data object D02. Moreover, 
computer stations 111, 112 may store data objects D03' and D03", 
respectively, representing the same data as data object D03. Each of computer 
stations 111,112 stores a respective status object in relation to each of its data 
objects. Correspondingly, computer station 1 1 1 stores status objects SOI' and 

30 S03', and computer station 112 stores status objects SQ2" and S03". 
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Because asynchronous messaging is used for communication between 
computer stations 110, 111, 112 ...a user accessing a data object on one 
computer has no real time view of a corresponding data object stored on 
another computer. To synchronize the various data objects (or data sets), 
5 electronic messages are exchanged between users operating on the same data 
to notify each other of modifications applied to the data. When such a 
notification message is received by a computer station of a user, the 
corresponding data object stored on this computer station is adjusted 
accordingly. In this way, best possible up-to-dateness of all data objects 
10 representing the same data can be achieved. 

In the following, the present invention will be set forth by way of an exemplary, 
non-limiting embodiment with reference to the flowchart diagram of Fig. 2 and 
the graphical presentation depicted in Fig. 3. In this exemplary embodiment, the 
15 invention is implemented using the network topology illustrated in, and explai- 
ned with respect to, Fig. 1. The messaging methodology according to the pre- 
sent invention can be implemented regardless of the structure, format, and type 
of data that are hosted, stored, processed, etc. 

20 In the exemplary embodiment, modifications are applied to data object DOI by 
a user of computer station 110 and notification of these modifications is from 
computer station 1 10 to computer station 111. It is to be understood, however, 
that the principles of the present invention as laid out herein are likewise 
applicable to the notification of modifications in the opposite direction, i.e., from 

25 computer station 1 1 1 to computer station 110, between any other pair or group 
of participants, and in relation to any other data object. Thus, the following 
description of the exemplary embodiment is by no means intended to be limiting 
to the scope of the present invention. In particular, notification of modifications 
of one or more data objects can be from one participant to more than one other 

30 participant, for example, to all other participants of computer system 100 or only 
a part number of other participants. Also, one or more participants other than 
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computer station 110 can be equipped with a computer program product 
embodying the messaging methodology of the present invention. 

Fig. 2 illustrates a routine for a notification process that is executed by 
5 processor 130 of computer station 110 under control of the CPP. As indicated in 
the flowchart diagram of Fig. 2, processor 130 checks a modification status flag 
MSF provided in relation to data object DOI . This flag is stored in memory 140 
or in an internal register of processor 130. It can assume either of two binary 
values and indicates a modification status of data object DOI. Specifically, in an 

10 initial state (i.e., before any modification of data object DOI), flag MSF is set to 
a value "0" indicating that data object DOI is unchanged. Upon entry of a first 
modification of data object DOI , processor 130 sets flag MSF to a value "1" 
indicating that data object DOI has been changed. Flag MSF is reset to value 
"0" only until after a notification message has been sent to computer station 

15 1 1 1 . If thereafter a further modification of data object DOI is entered, flag MSF 
is set again to "1". Setting and resetting of flag MSF is through corresponding 
control signals generated internally by processor 130. 

If it is determined that flag MSF is "0", the routine is not executed further as data 
20 object DOI has not been changed since its generation or since any last 

notification message. On the other hand, if it is determined that flag MSF is set 
to "1", this indicates that data object DOI has been changed and the change 
needs to be communicated to computer station 111. 

25 Thereafter, the routine advances to check another binary flag called 

communication status flag CSF. This flag serves to indicate a communication 
status in relation to modifications applied to data object DOI. Specifically, a 
value "0" of flag CSF indicates that no notification message in relation to data 
object DOI is underway or waiting for acknowledgment by computer station 

30 111. Thus, value "0" of flag CSF indicates a free notification path, allowing 
computer station 1 10 to send a notification message to computer station 111. 
On the other hand, a value "1" of flag CSF indicates a busy notification path, 
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requiring computer station 1 10 to wait for a confirmation message from 
computer station 1 1 1 before being allowed to send a further notification 
message. 

5 It is to be understood that when referring to a busy notification path, no physical 
blockage due to, e.g., overload of network 120 or the like is meant. Rather, flag 
CSF simply reflects the concept of a pessimistic communication protocol where 
sending of a notification message is not allowed until confirmation of a previous 
notification message is received. In this regard, a busy notification path is a 
10 mere reference to a situation where a notification message has been sent off by 
computer station 110 and no acknowledgment of receipt of that notification 
message by computer station 111 has yet been received on the part of 
computer station 110. 

15 Flag CSF will also be stored in memory 140 or in an internal register of 

processor 130. Suitable control signals will be generated by processor 130 to 
effect setting and resetting of flag CSF. 

If it is determined that flag CSF is set to value "1", no new notification message 
20 can be created and sent off. Then, the routine enters a waiting loop repeating 
checking flag CSF, which is only reset to "0" after receipt of a confirmation 
message from computer station 111 confirming receipt of an earlier notification 
message. On the other hand, if it is determined that flag CSF is set to "0", 
processor 130 proceeds by reading status object SOI and creating a 
25 notification message that contains the information read from status object SOI . 
Thereafter, computer station 110 sends the notification message over network 
120 to computer station 111. 

The status information packed in a notification message can result from a single 
30 change to data object DOI , or from multiple changes. The methodology of the 
present invention allows a user to enter modifications of data object DOI 
regardless of whether or not the notification path from computer station 1 10 to 
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computer station is busy. As changes made to data object DOI are 
accumulated in status object SOI, changes do not need to be communicated to 
computer station 1 1 1 as they are entered. Rather, whenever the notification 
path from computer station 1 10 to computer station 1 1 1 becomes available, the 
5 current status of data object DOI is retrieved, which reflects all modifications 
applied up to now. 

In the flowchart diagram of Fig. 2, in a next step following sending-off of the 
notification message, flag CSF is set to value "1", indicating that the notification 

10 path from computer station 1 1 0 to computer station 1 1 1 is busy and cannot be 
used for sending a further notification message until an acknowledgment is 
received from computer station 1 1 1 . At the same time, flag MSF is reset to 
value "0", indicating that the present (modified) status of data object DOI has 
been communicated to computer station 1 1 1 . As soon as an acknowledgment 

15 in the form of a confirmation message is received by computer station 110, flag 
CSF is also reset to value "0". After a notification message has been 
successfully sent off, the flow returns to the beginning of the routine to check on 
flag MSF. If no further modification of data object DOI has been entered in the 
meantime by the user, flag MSF will still be set to "0". If, however, the user has 

20 made a further change to data object DOI , flag MSF will indicate "1", and the 
procedure outlined above is executed again. 

Fig. 3 depicts an exemplary graphical user interface that can be presented to 
the user of computer station 1 1 0 on a display DIS of output device 1 70 under 

25 control of the CPP. Display DIS comprises two portions (windows), one for 

displaying the modification state of data objects D01, D02, D03 ... and one for 
displaying these data objects' current status as given by status objects SOI, 
S02, S03 ... For example, the data object window may present a display item 
IT1 in relation to every data object of which the modification status flag MSF 

30 indicates "1", and present a display item \TV in relation to every data object of 
which the modification status flag MSF indicates "0". In the exemplary 
presentation illustrated in Fig. 3, display items IT1 and ITT both include a 
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graphical symbol in the form of a small rectangle plus a written remark, but 
differ from each other, e.g., in the color of the rectangle and the text used for the 
written remark. In this way, the user can tell with ease from the presentation on 
the display DIS which data object has been modified and is waiting for being 
5 communicated to other participants. Of course, rectangles and text phrases are 
mere examples of display items that can be used to graphically symbolize 
modified and unmodified data objects. Many other ways of presenting in a 
graphical manner, information on the modification and notification status of the 
data objects are readily available to one skilled in the art. 

10 

In the other display window (status object window), a display item IT2 may be 
presented that indicates the current content of the status object of a data object. 
Particularly, only one status object may be presented at a time as controlled by 
the user selecting one of the data objects in the data object window with, e.g., a 
15 mouse pointer device. 

Whenever a notification message has been sent, processor 130 may cause an 
update of the presentation in the data object window, and whenever the user 
enters a modification of a data object, processor may cause an update of the 
20 presentation in the status object window if the corresponding status object is 
presently displayed. 

The present invention as implemented in computer system 100 allows changes 
to be made to a local data object, e.g., a purchase order object, without violating 

25 the requirements of a pessimistic communication protocol. It can be viewed as 
providing a mixed pessimistic/optimistic protocol that supports open communi- 
cation protocols like RosettaNet externally, i.e., for communication between 
computer stations 110,111,112... while at the same time supporting tolerant 
and flexible protocols internally, i.e., for entry of modifications locally at each 

30 computer station. The invention thus allows to realize and implement a secure 
and reliable messaging protocol in an open architecture computer system while 
providing unmatched flexibility and customer friendliness. 
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While the messaging methodology of the present invention can be used for 
communication between all participants of a distributed computer system, it is 
likewise conceivable to employ the messaging methodology of the present 
5 invention for communication between some of the participants only and use 
another communication protocol for communication between other participants. 
For example, the same sender application may communicate with two receiver 
applications, using the messaging methodology of the present invention for 
communication with one of the receiver applications and a pure optimistic 
10 protocol for communication with the other receiver application. 

While the invention has been described with reference to a preferred embodi- 
ment, those skilled in the art will readily appreciate that various changes may be 
made without departing from the scope of the invention. The invention is 
15 therefore intended to include all embodiments that fall within the scope of the 
appended claims. 



